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ABSTRACT 

Rc is a command interpreter for Plan 9. It also runs on a variety of traditional sys- 
tems, including SunOS and the Tenth Edition. It provides similar facilities to Bourne’s 
/bin/sh, with some small additions and mostly less idiosyncratic syntax. This paper intro- 
duces re’s highlights with numerous examples, and discusses its design and why it varies 
from Bourne’s. 


1. Introduction 

Plan 9 needs a command-programming language. As porting the Bourne shell to an incompatible new 
environment seemed a daunting task, I chose to write a new command interpreter, called rc because it runs 
commands. Although tinkering with perfection is a dangerous business, I could hardly resist trying to 
‘improve’ on Bourne’s design. Thus rc is similar in spirit but different in detail from Bourne’s shell. 

The bulk of this paper describes re’s principal features with many small examples and a few larger ones. 
We close with a discussion of the principles guiding re’s design and why it differs from Bourne’s design. 
The descriptive sections include little discussion of the rationale for particular features, as individual details 
are hard to justify in isolation. The impatient reader may wish to skip to the discussion at the end before 
skimming the expository parts of the paper. 

2. Simple commands 

For the simplest uses rc has syntax familiar to Bourne-shell users. Thus all of the following behave as 
expected: 

date 

con alice 
who >user. names 
who »user. names 
wc <file 
echo [a- f ] * . c 
who I wc 
who; date 
cc * . c & 

cyntax *.c && cc -g -o cittd *.c 
rm -r junk I I echo rm failed! 


3. Quotation 

An argument that contains a space or one of re’s other syntax characters must be enclosed in apostrophes 
('): 

rm 'odd file name' 

An apostrophe in a quoted argument must be doubled: 
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echo 'How''s your father?' 


4. Variables 

Rc provides variables whose values are lists of arguments. Variables may be given values by typing, for 
example: 

path= ( . /bin /usr/bin) 

user=td 

tty=/dev/tty8 

The parentheses indicate that the value assigned to path is a list of three strings. The variables user and 
tty are assigned lists containing a single string. 

The value of a variable can be substituted into a command by preceding its name with a $, like this: 

echo $path 

If path had been set as above, this would be equivalent to 

echo . /bin /usr/bin 

Variables may be subscripted by numbers or lists of numbers, like this: 

echo $path(2) 
echo $path(3 2 1) 

These are equivalent to 

echo /bin 

echo /usr/bin /bin . 

There can be no space separating the variable’s name from the left parenthesis. Otherwise, the subscript 
would be considered a separate parenthesized list. 

The number of strings in a variable can be determined by the $ # operator. For example, 

echo $#path 

would print the number of entries in $path. 

The following two assignments are subtly different: 

empty = ( ) 
null= ' ' 

The first sets empty to a list containing no strings. The second sets null to a list containing a single 
string, but the string contains no characters. 

Although these may seem like more or less the same thing (in Bourne’s shell, they are indistinguishable), 
they behave differently in almost all circumstances. Among other things 

echo $#empty 

prints 0, whereas 

echo $#null 
prints 1. 

All variables that have never been set have the value ( ) . 

5. Arguments 

When rc is reading its input from a file, the file has access to the arguments supplied on re’s command line. 
The variable $* initially has the list of arguments assigned to it. The names $1, $2, etc. are synonyms for 
$ * ( 1 ) , $ * ( 2 ) , etc. In addition, $ 0 is the name of the file from which re’s input is being read. 
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6. Concatenation 

Rc has a string concatenation operator, the caret ", to build arguments out of pieces. 

echo hully '"gully 
is exactly equivalent to 

echo hully gully 

Suppose variable i contains the name of a command. Then 

cc -o $i $i~.c 

might compile the command’s source code, leaving the result in the appropriate file. 

Concatenation distributes over lists. The following 

echo (a b c) " (1 2 3) 
src=(main subr io) 
cc $src'".c 

are equivalent to 

echo al b2 c3 
cc main.c subr.c io.c 

In detail, the rule is: if both operands of ~ are lists of the same non-zero number of strings, they are con- 
catenated pairwise. Otherwise, if one of the operands is a single string, it is concatenated with each mem- 
ber of the other operand in turn. Any other combination of operands is an error. 

7. Free carets 

User demand has dictated that rc insert carets in certain places, to make the syntax look more like the 
Bourne shell. For example, this: 

cc -$flags $stems.c 

is equivalent to 

cc -"Sflags $stems".c 

In general, rc will insert ~ between two arguments that are not separated by white space. Specifically, 
whenever one of $ ' ' follows a quoted or unquoted word, or an unquoted word follows a quoted word with 
no intervening blanks or tabs, a " is inserted between the two. If an unquoted word immediately following 
a $ contains a character other than an alphanumeric, underscore or *, a " is inserted before the first such 
character. 

8. Command substitution 

It is often useful to build an argument list from the output of a command. Rc allows a command, enclosed 
in braces and preceded by a left quote, '{•••}, anywhere that an argument is required. The command is 
executed and its standard output captured. The characters stored in the variable if s are used to split the 
output into arguments. For example, 

cat '{Is -trlsed 10q} 

will catenate the ten oldest files in the current directory in temporal order. 

9. Pipeline branching 

The normal pipeline notation is general enough for almost all cases. Very occasionally it is useful to have 
pipelines that are not linear. Pipeline topologies more general than trees can require arbitrarily large pipe 
buffers, or worse, can cause deadlock. Rc has syntax for some kinds of non-linear but treelike pipelines. 
For example, 


cmp <{old} <{new} 
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will regression test a new version of a command. < or > followed by a command in braces causes the com- 
mand to be run with its standard output or input attached to a pipe. The parent command (cmp in the exam- 
ple) is started with the other end of the pipe attached to some file descriptor or other, and with an argument 
that will connect to the pipe when opened (e.g. /dev/ f <3/ 6.) On systems without /dev/fd or some- 
thing similar (SunOS for example) this feature does not work. 

10. Exit status 

When a command exits it returns status to the program that executed it. On Plan 9 status is a character 
string describing an error condition. On normal termination it is empty. 

Rc captures commands’ exit statuses in the variable $status. For a simple command the value of 
$status is just as described above. For a pipeline $status is set to the concatenation of the statuses of 
the pipeline components with I characters for separators. 

Rc has a several kinds of control flow, many of them conditioned by the status returned from previously 
executed commands. Any $status containing only 0’s and I ’s has boolean value true. Any other status 
is false. 

11. Command grouping 

A sequence of commands enclosed in { } may be used anywhere a command is required. For example: 

{sleep 3600;echo 'Time''s up!'}& 
will wait an hour in the background, then print a message. Without the braces: 

sleep 3600; echo 'Time''s up! '& 

this would lock up the terminal for an hour, then print the message in the background! 

12. Control flow — for 

A command may be executed once for each member of a list by typing, for example: 

for(i in printf scanf putchar) look $i /usr/td/lib/dw.dat 
This looks for each of the words printf, scanf and putchar in the given file. The general form is 
for (name in list) command 

or 

for (name) command 

In the first case command is executed once for each member of list with that member assigned to variable 
name. If in list is not given, $* is used. 

13. Conditional execution — if 

Rc also provides a general if-statement. For example: 

iffcyntax *.c) cc -g -o cmd *.c 

runs the C compiler whenever cyntax finds no problems with * .c. An ‘if not’ statement provides a 
two-tailed conditional. For example: 

for (i) { 

if (test -f /tmp/$i) echo $i already in /tmp 
if not cp $i /tmp 

} 

This loops over each file in $ *, copying to / tmp those that do not already appear there, and printing a mes- 
sage for those that do. 
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14. Control flow — while 

Re's while statement looks like this: 

while(newer subr.c subr.o) sleep 5 

This waits until subr . o is newer than subr . c (presumably because the C compiler finished with it.) 

15. Control flow — switch 

Rc provides a switch statement to do pattern-matching on arbitrary strings. Its general form is 

switch (word) { 
case pattern ... 

commands 
case pattern... 
commands 

} 

Rc attempts to match the word against the patterns in each case statement in turn. Patterns are the same as 
for filename matching, except that / and the first characters of . and . . need not be matched explicitly. 

If any pattern matches, the commands following that case up to the next case (or the end of the switch) are 
executed, and execution of the switch is complete. For example, 

switch($#*) { 
case 1 

cat »$1 
case 2 

cat »$2 <$1 
case * 

echo 'Usage: append [from] to' 

1 

is an append command. Called with one file argument, it tacks standard input to its end. With two, the first 
is appended to the second. Any other number elicits a usage message. 

The built-in ~ command also matches patterns, and is often more concise than a switch. Its arguments are a 
string and a list of patterns. It sets $status to true if and only if any of the patterns matches the string. 
The following example processes option arguments for the man( 1) command: 

opt=() 

while (~ $1 -* [1-9] 10) { 
switch ($1) { 
case [1-9] 10 

sec=$l secn=$l 
case -f 

c=f s=f 
case - [qwnt] 
cmd=$l 
case -T* 

T=$l 
case -* 

opt=($opt $1) 

} 

shift 

} 
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16. Functions 

Functions may be defined by typing 

fn name { commands } 

Subsequently, whenever a command named name is encountered, the remainder of the command’s argu- 
ment list will assigned to $ * and rc will execute the commands. The value of $ * will be restored on com- 
pletion. For example: 

fn g { 

gre -e $1 * . [hcyl ] 

} 

defines g pattern to look for occurrences of pattern in all program source files in the current directory. 
Function definitions are deleted by writing 
fn name 

with no function body. 

17. Command execution 

Up to now we’ve said very little about what rc does to execute a simple command. If the command name 
is the name of a function defined using f n, the function is executed. Otherwise, if it is the name of a built- 
in command, the built-in is executed directly by rc. Otherwise, if the name contains a /, it is taken to be 
the name of a binary program and is executed using exec{ 2). If the name contains no /, then directories 
mentioned in the variable $path are searched until an executable file is found. 

18. Built-in commands 

Several commands are executed internally by rc because they are difficult or impossible to implement oth- 
erwise. 

. [ — i ] file... 

Execute commands from file. $* is set for the duration to the reminder of the argument list follow- 
ing file. $path is used to search for file. Option - i indicates interactive input - a prompt (found in 
$prompt) is printed before each command is read. 

builtin command... 

Execute command as usual except that any function named command is ignored. For example, 

fn cd{ 

builtin cd $* && pwd 

} 

defines a replacement for the cd built-in (see below) that announces the full name of the new direc- 
tory. 

cd [dir] 

Change the current directory to dir. The default argument is $home. $cdpath is a list of places in 
which to search for dir. 

eval [arg... ] 

The arguments are catenated separated by spaces into a string, read as input to rc, and executed. For 
example, 

x= ' $y ' 
y=Doody 

eval echo Howdy, $x 

would echo 

Howdy , Doody 

since the arguments of eval would be 
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echo Howdy, $y 

after substituting for $x. 
shift [n] 

Delete the first n (default 1) elements of $ *. 
wait [pid] 

Wait for the process with the given pid to exit. If no pid is given, all outstanding processes are 
waited for. 
what is name ... 

Print the value of each name in a form suitable for input to rc. The output is an assignment to a vari- 
able, the definition of a function, a call to built in for a built-in command, or the path name of a 
binary program. For example, 

whatis path g cd who 

might print 

path= ( . /bin /usr/bin) 
fn g {gre -e $1 *.[hycl]} 
builtin cd 
/bin /who 

~ subject pattern ... 

The subject is matched against each pattern in turn. On a match, $status is set to true. Otherwise, 
it is set to 'no match'. Patterns are the same as for filename matching. The patterns arc not sub- 
jected to filename replacement before the ~ command is executed, so they need not be enclosed in 
quotation marks, unless of course, a literal match for * [ or ? is required. For example 

~ $1 ? 

matches any single character, whereas 

~ $l '?' 

only matches a literal question mark. 

19. Advanced I/O Redirection 

Rc allows redirection of file descriptors other than 0 and 1 (standard input and output) by specifying the file 
descriptor in square brackets [ ] after the < or >. For example, 

cc junk.c >[2] junk.diag 

saves the compiler’s diagnostics in junk . diag. 

File descriptors may be replaced by a copy, in the sense of dup(2), of an already-open file by typing, for 
example 

cc junk.c >[2=1] 

This replaces file descriptor 2 with a copy of file descriptor 1. It is more useful in conjunction with other 
redirections, like this 

cc junk.c >junk.out >[2=1] 

Redirections are evaluated from left to right, so this redirects file descriptor 1 to junk . out, then points 
file descriptor 2 at the same file. By contrast, 

cc junk.c >[2=1] >junk.out 

Redirects file descriptor 2 to a copy of file descriptor 1 (presumably the terminal), and then directs file 
descriptor 1 at a file. In the first case, standard and diagnostic output will be intermixed in junk . out. In 
the second, diagnostic output will appear on the terminal, and standard output will be sent to the file. 

File descriptors may be closed by using the duplication notation with an empty right-hand side. For 
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example, 

cc junk.c >[2=] 

will discard diagnostics from the compilation. 

Arbitrary file descriptors may be sent through a pipe by typing, for example 

cc junk.c I [2] grep -v 

This deletes those ever-so-annoying blank lines from the C compiler’s output. Note that the output of 
grep still appears on file descriptor 1. 

Very occasionally you may wish to connect the input side of a pipe to some file descriptor other than zero. 
The notation 

cmdl I [5=19] cmd2 

creates a pipeline with cmdl’s file descriptor 5 connected through a pipe to cmd2’s file descriptor 19. 

20. Here documents 

Rc procedures may include data, called “here documents”, to be provided as input to commands, as in this 
version of the tel command 

for(i) grep $i «! 

nls 2T-402 2912 
norman 2C-514 2842 
pjw 2T-502 7214 

I 

A here document is introduced by the redirection symbol «, followed by an arbitrary eof marker ( ! in the 
example). Lines following the command, up to a line containing only the eof marker are saved in a tempo- 
rary file that it connected to the command’s standard input when it is run. 

Rc does variable substitution in here documents. The following subst command: 

ed $3 «EOF 

g/$l/s//$2/g 

w 

EOF 

changes all occurrences of $1 to $2 in file $3. To include a literal $ in a here document, type $$. If the 
name of a variable is followed immediately by ", the caret is deleted. 

Variable substitution can be entirely suppressed by enclosing the eof marker following « in quotation 
marks. 

Here documents may be provided on file descriptors other than 0 by typing, for example 

cmd « [ 4 ] End 

End 

21. Signals 

Rc scripts normally terminate when an interrupt is received from the terminal. A function with the name of 
a signal, in lower case, is defined in the usual way, but called when rc receives the signal. Signals of inter- 
est are: 
sighup 

Hangup. The controlling teletype has disconnected from rc. 

sigint 

The interrupt character (usually ASCII del) was typed on the controlling terminal. 
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sigquit 

The quit character (usually ASCII fs, ctrl-\) was typed on the controlling terminal. 

sigterm 

This signal is normally sent by kill(l). 
sigexit 

An artificial signal sent when rc is about to exit. 

As an example, 

fn sigint{ 

rm /tmp/junk 
exit 

} 

sets a trap for the keyboard interrupt that removes a temporary file before exiting. 

Signals will be ignored if the signal routine is set to { } . Signals revert to their default behavior when their 
handlers’ definitions are deleted. 

22. Environment 

The environment is a list of name-value pairs made available to executing binaries. On Plan 9, the environ- 
ment is stored in a file system named #e, normally mounted on /env. The value of each variable is stored 
in a separate file, with components terminated by ASCII nuls. (This is not quite as horrendous as it sounds, 
the file system is maintained entirely in core, so no disk or network access is involved.) The contents of 
/ env are shared on a per-process group basis - when a new process group is created it effectively attaches 
/env to a new file system initialized with a copy of the old one. A consequence of this organization is that 
commands can change environment entries and see the changes reflected in rc. 

There is not currently a way on Plan 9 to place functions in the environment, although this could easily 
done by mounting another instance of #e on another directory. The problem is that currently there can be 
only one instance of #e per process group. 

23. Local Variables 

It is often useful to set a variable for the duration of a single command. An assignment followed by a com- 
mand has this effect. For example 

a=global 
a=local echo $a 
echo $a 

will print 

local 

global 

This works even for compound commands, like 

f =/falrly/long/file/name { 

{ wc $f ; spell $f ; dlff $f.old $f } I 
pr -h 'Facts about '$f I lp -ddp 

} 


24. Examples — cd, pwd 

Here is a pair of functions that provide enhanced versions of the standard cd and pwd commands. (Thanks 
to Rob Pike for these.) 
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psl='% ' # default prompt 

tab=' ' # a tab character 

fn pbd{ 

/bin/pwd|sed 's 

} 

fn cd{ 

builtin cd $1 && 
switch($#*) { 
case 0 

dir=$home 
prompt=($psl $tab) 
case * 

switch ($1) 
case /* 
dir=$l 

prompt= (' {pbd} "Spsl $tab) 
case * /* . . * 
dir= ( ) 

prompts ( ' {pbd} ''Spsl $tab) 
case * 
dir= ( ) 

prompts ($l"$psl $tab) 

} 

} 

} 

fn pwd{ 

if (~ $#dir 0) 
dir=' {/bin/pwd} 
echo $dir 

} 

Function pwd is a version of the standard pwd that caches its value in variable $dir, because the genuine 
pwd can be quite slow to execute. 

Function pbd is a helper that prints the last component of a directory name. Function cd calls the cd 
built-in, and checks that it was successful. If so, it sets $dir and $prompt. The prompt will include the 
last component of the current directory (except in the home directory, where it will be null), and $dir will 
be reset either to the correct value or to { ) , so that the pwd function will work correctly. 

25. Examples — man 

The man command prints pages from of the Programmer’s Manual. It is called, for example, as 

man 3 isatty 
man rc 
man -t cat 

In the first case, the page for isatty in section 3 is printed. In the second case, the manual page for rc is 
printed. Since no manual section is specified, all sections are searched for the page, and it is found in sec- 
tion 1. In the third case, the page for cat is typeset (the -t option). 
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ed /n/bowell/usr/man I I { 

echo $0: Manual not on line! >[1=2] 
exit 1 

} 

NT=n # default nroff 
s='*' # section, default try all 
f or ( i ) swi tch ( $i ) { 
case -t 
NT=t 
case -n 
NT=n 
case -* 

echo Usage: $0 ' [-nt] [section] page >[1=2] 

exit 1 

case [1-9] 10 
s=$i 
case * 

eval 'pages=man' $s/$i' . * ' 
for (page in $pages) { 
if (test -f $page) 

$NT , 'roff -man $page 
if not 

echo $0: $i not found >[1=2] 

} 

} 

Note the use of eval to make a list of candidate manual pages. Without eval, the * stored in $s would 
not trigger filename matching — it’s enclosed in quotation marks, and even if it weren’t, it would be 
expanded when assigned to $s. Eval causes its arguments to be re-processed by re’s parser and interpreter, 
effectively delaying evaluation of the * until the assignment to $pages. 

26. Examples — holmdel 

The following rc script plays the deceptively simple game holmdel, in which the players alternately name 
Bell Labs locations, the winner being the first to mention Holmdel. 

This script is worth describing in detail (rather, it would be if it weren’t so silly.) 

Variable $t is an abbreviation for the name of a temporary file. Including $pid, initialized by rc to its 
process-id, in the names of temporary files insures that their names won’t collide, in case more than one 
instance of the script is running at a time. 

Function read’s argument is the name of a variable into which a line gathered from standard input is read. 
$ i f s is set to just a newline. Thus read’ s input is not split apart at spaces, but the terminating newline is 
deleted. 

A handler is set to catch sigint, sigquit, and sighup, and the artificial sigexit signal. It just 
removes the temporary file and exits. 

The temporary file is initialized from a here document containing a list of Bell Labs locations, and the main 
loop starts. 

First, the program guesses a location (in $lab) using the fortune program to pick a random line from 
the location list. It prints the location, and if it guessed Holmdel, prints a message and exits. 

Then it uses the read function to get lines from standard input and validity-check them until it gets a legal 
name. Note that the condition part of a whi le can be a compound command. Only the exit status of the 
last command in the sequence is checked. 

Again, if the result is Holmdel, it prints a message and exits. Otherwise it goes back to the top of the loop. 
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t=/tmp/holmdel$pid 
fn read{ 

$l='{awk ' {print;exit} ' } 

} 

ifs=' 

' # just a newline 

fn sigexit sigint sigquit sighup{ 
rm - f $ t 
exit 

} 

cat « ' ! ' >$t 

Allentown 

Atlanta 

Cedar Crest 

Chester 

Columbus 

Elmhurst 

Fullerton 

Holmdel 

Indian Hill 

Merrimack Valley 

Morristown 

Piscataway 

Reading 

Short Hills 

South Plainfield 

Summit 

Whippany 

West Long Branch 

i 

while (true) { 

lab= ' { /usr/games/fortune $t} 
echo $lab 

if(~ $lab Holmdel) { 
echo You lose, 
exit 

} 

while (read lab; ! grep -i -s $lab $t) echo No such location. 
if(~ $lab [hH]olmdel) { 
echo You win. 
exit 

} 

} 

27. Discussion 

Steve Bourne’s /bin/sh is extremely well-designed; any successor is bound to suffer in comparison. I 
have tried to fix its best-acknowledged shortcomings and to simplify things wherever possible, usually by 
omitting unessential features. Only when irresistibly tempted have I introduced novel ideas. Obviously I 
have tinkered extensively with Bourne’s syntax, that being where his work was most open to criticism. 

The most important principle in re’s design is that it’s not a macro processor. Input is never scanned more 
than once by the lexical and syntactic analysis code (except, of course, by the eval command, whose 
raison d’etre is to break the rule). 

Bourne shell scripts can often be made to run wild by passing them arguments containing spaces. These 
will be split into multiple arguments using IFS, often as inopportune times. In rc, values of variables, 
including command line arguments, are not re-read when substituted into a command. Arguments have 
presumably been scanned in the parent process, and ought not to be re-read. 

Why does Bourne re-scan commands after variable substitution? He needs to be able to store lists of 
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arguments in variables whose values are character strings. If we eliminate re-scanning, we must change the 
type of variables, so that they can explicitly carry lists of strings. 

This introduces some conceptual complications. We need a notation for lists of words. There are two dif- 
ferent kinds of concatenation, for strings — $a~$b, and lists — ( $a $b) . The difference between ( ) 
and ' ' is confusing to novices, although the distinction is arguably sensible — a null argument is not the 
same as no argument. 

Bourne also rescans input when doing command substitution. This is because the text enclosed in back- 
quotes is not properly a string, but a command. Properly, it ought to be parsed when the enclosing com- 
mand is, but this makes it difficult to handle nested command substitutions, like this: 

size='wc -1 Vis -tlsed lqV' 

The inner back-quotes must be escaped to avoid terminating the outer command. This can get much worse 
than the above example; the number of \’s required is exponential in the nesting depth. Rc fixes this by 
making the backquote a unary operator whose argument is a command, like this: 

size='{wc -1 '{Is -tlsed lq} } 

No escapes are ever required, and the whole thing is parsed in one pass. 

For similar reasons rc defines signal handlers as though they were functions, instead of associating a string 
with each signal, as Bourne does, with the attendant possibility of getting a syntax error message in 
response to typing the interrupt character. Since rc parses input when typed, it reports errors when you 
make them. 

For all this trouble, we gain substantial semantic simplifications. There is no need for the distinction 
between $* and $@. There is no need for four types of quotation, nor the extremely complicated rules that 
govern them. In rc you use quotation marks exactly when you want a syntax character to appear in an argu- 
ment. IFS is no longer used, except in the one case where it was indispensable: converting command out- 
put into argument lists during command substitution. 

This also avoids an important security hole [Ree88]. System( 3) and popen( 3) call /bin/sh to execute a 
command. It is impossible to use either of these routines with any assurance that the specified command 
will be executed, even if the caller of system or popen specifies a full path name for the command. This can 
be devastating if it occurs in a set-userid program. The problem is that IFS is used to split the command 
into words, so an attacker can just set IFS=/ in his environment and leave a Trojan horse named usr or 
bin in the current working directory before running the privileged program. Rc fixes this by not ever res- 
canning input for any reason. 

Most of the other differences between rc and the Bourne shell are not so serious. I eliminated Bourne’s 
peculiar forms of variable substitution, like 

echo ${a=b} ${c-d} ${e?error} 

because they are little used, redundant and easily expressed in less abstruse terms. I deleted the builtins 
export, readonly, break, continue, read, return, set, times and unset because they seem 
redundant or only marginally useful. 

Where Bourne’s syntax draws from Algol 68, re’s is based on C or Awk. This is harder to defend. I 
believe that, for example 

if (test -f junk) rm junk 

is better syntax than 

if test -f junk; then rm junk; fi 

because it is less cluttered with keywords, it avoids the semicolons that Bourne requires in odd places, and 
the syntax characters better set off the active parts of the command. 

The one bit of large-scale syntax that Bourne unquestionably does better than rc is the if statement with 
else clause. Re's i f has no terminating f i-like bracket. As a result, the parser cannot tell whether or not 
to expect an else clause without looking ahead in its input. The problem is that after reading, for example 
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if(test -f junk) echo junk found 

in interactive mode, rc cannot decide whether to execute it immediately and print $prompt ( 1 ) , or to 
print $prompt ( 2 ) and wait for the else to be typed. In the Bourne shell, this is not a problem, because 
the i f command must end with f i , regardless of whether it contains an e 1 s e or not. 

Re’s admittedly feeble solution is to declare that the else clause is a separate statement, with the semantic 
proviso that it must immediately follow an i f , and to call it i f not rather than else, as a reminder that 
something odd is going on. The only noticeable consequence of this is that the braces are required in the 
construction 

for (i ) { 

if (test -f $i) echo $1 found 
if not echo $i not found 

} 

and that rc resolves the “dangling else” ambiguity in opposition to most people’s expectations. 

It is remarkable that in the four most recent editions of the UNIX system programmer’s manual the Bourne 
shell grammar described in the manual page does not admit the command who I wc. This is surely an over- 
sight, but it suggests something darker: nobody really knows what the Bourne shell’s grammar is. Even 
examination of the source code is little help. The parser is implemented by recursive descent, but the rou- 
tines corresponding to the syntactic categories all have a flag argument that subtly changes their operation 
depending on the context. Re’s parser is implemented using yacc, so I can say precisely what the grammar 
is. 

Its lexical structure is harder to describe. I would simplify it considerably except for two things. There is a 
lexical kludge to distinguish between parentheses that immediately follow a word with no intervening 
spaces and those that don’t that I would eliminate if there were a reasonable pair of characters to use for 
subscript brackets. I could also eliminate the insertion of free Carets if users were not adamant about it. 
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